OpenSSH 8.0 est disponible depuis le 17 avril 2019. Ce projet, démarré par des développeurs d’OpenBSD, vise à proposer une alternative libre, sécurisée et moderne à des logiciels d’administration distante comme telnet et rlogin. Le but est d’ailleurs atteint, puisque ces deux derniers logiciels ont été relégués au rang d’antiquités depuis bien des années maintenant.
Vous trouverez en deuxième partie de cet article une sélection des changements apportés, reprenant grandement les notes de version.
Sommaire
Sécurité
Cette nouvelle version corrige en particulier une faiblesse dans scp (le programme ainsi que le protocole), identifiée par le numéro CVE-2019-6111 : en cas de copie de fichiers d’une machine distante dans un répertoire local, scp ne vérifiait pas si les noms des fichiers envoyés par le serveur correspondaient à ceux demandés par le client. Cela permettait à un serveur malveillant de créer ou de modifier des fichiers sur le système du client.
Dans les notes de version, les développeurs ajoutent que le protocole SCP est dépassé, rigide et difficile à corriger. Ils continuent en recommandant l’utilisation d’un protocole plus moderne comme SFTP et rsync pour le transfert de fichiers.
Changements pouvant casser la compatibilité ascendante
Comme à chaque note de version, les développeurs mettent en garde les utilisateurs à propos de changements qui pourraient poser problème sur des configurations existantes. Pour cette version, deux changements sont à surveiller de près :
-
pour scp, des vérifications ont été ajoutées afin de refuser des fichiers si l’expansion de caractères spéciaux diffère entre le client et le serveur ; au cas où, l’argument «
-T
» désactive ce comportement ; -
pour sshd, la syntaxe «
hôte/port
», jugée obsolète, n’est plus utilisable pour les directivesListenAddress
etPermitOpen
; elle avait été ajoutée en 2001 en tant qu’alternative à la syntaxe «hôte:port
», mais elle est souvent confondue avec une syntaxe de type CIDR.
Changements depuis OpenSSH 7.9
Nouvelles fonctionnalités
Parmi les nouveautés d’OpenSSH 8.0, on peut trouver :
-
ssh(1)
,ssh-agent(1)
,ssh-add(1)
: ajout de la prise en charge de clefs ECDS dans les jetons PKCS#11 ; -
ssh(1)
,sshd(8)
: ajout d’une méthode expérimentale d’échange de clefs résistante à l’informatique quantique, basée sur une combinaison de streamlined NTRU prime 4591761 et X25519 ; -
ssh-keygen(1)
: augmentation de la taille par défaut des clefs RSA à 3072 bits, cela suit une recommandation du NIST, émise dans la publication spéciale 800-57 ; -
ssh(1)
: en cas de demande d’enregistrement d’une nouvelle clef d’hôte, il est possible d’entrer une empreinte de clef à la place de yes ou no, ce qui permet d’en coller une provenant, par exemple, d’un accès « hors ligne » et faire en sorte que le client SSH compare (et accepte ou refuse) à la place de l’utilisateur ; - l’argument
-J
est disponible en tant qu’alias de l’optionProxyJump
dans les outils scp et sftp ; -
ssh-agent(1)
,ssh-pkcs11-helper(8)
etssh-add(1)
: l’argument-v
augmente la verbosité de la sortie, mais passe aussi cette augmentation dans les sous‐processus, comme dans le cas oùssh-pkcs11-helper
est démarré depuisssh-agent
; -
sshd(8)
: la variable d’environnement$SSH_CONNECTION
est exposée à l’environnement PAM ; cela permet aux modules PAM d’utiliser le « connection 4‐tuple » (quadruplet de connexion).
À noter, pour ce qui est des tailles de clefs, qu’en France celles‐ci font l’objet d’une recommandation de l’ANSSI par le biais du Référentiel Général de Sécurité (RGS), et en particulier de son annexe B1.
Corrections de bogues
Cette nouvelle version apporte, entre autres, les corrections suivantes :
-
sshd(8)
n’envoie plus de keepalive en double quand la directiveClientAliveCount
est activée ; - deux race conditions (« situation de compétition, situation de concurrence, accès concurrents, concurrence critique, course critique, séquencement critique ») ont été corrigées dans
sshd(8)
, elles sont liées à son redémarrage viaSIGHUP
; la première concernant des descripteurs de fichiers restants pouvant empêchersshd
d’écouter sur l’adresse configurée, et l’autre concernant lesshd
parent qui redémarre, car il pouvait se fermer avant la fin de la lecture par tous les processus enfants en attente de leur état de ré‐exécution, les laissant ainsi dans un chemin de secours ; - correction d’une mauvaise interaction entre les directives
ConnectTimeout
etConnectionAttempts
dans le fichierssh_config
, les tentatives de connexion faites après la première ignoraient le délai d’expiration configuré ; -
ssh-keyscan(1)
a maintenant un code de retour autre que 0 quand il ne trouve aucune clef ; -
scp
va dorénavant nettoyer les noms de fichiers pour autoriser des caractères UTF-8 sans séquence de contrôle de terminal ; - la documentation de l’option
ProxyJump
(et de l’argument-J
) clarifie que la configuration locale ne s’applique pas aux hôtes de rebond ; - autre clarification, cette fois‐ci pour l’argument
-e
dessh-keygen
, qui n’écrit que des clefs publiques, et non privées ; -
ssh
etsshd
sont maintenant plus stricts sur le traitement des bannières de protocole, n’autorisant\r
qu’immédiatement après\n
; - un certain nombre de fuites de mémoires ont été corrigées, voir les bogues bz#2938 et bz#2942 ;
- le calcul de débit initial a été corrigé dans
scp
etsftp
: il prend maintenant en compte les octets écrits avant que le minuteur démarre et ajuste la programmation des recalculs de débit, ce qui évite un pic de trafic et applique mieux la limite ; - encore une clarification du manuel, cette fois concernant les arguments
-F
et-R
dessh-keygen
: ils acceptent, soit juste le nom d’hôte, soit la syntaxe[nom d’hôte]:port
; -
ssh
n’essaie plus de se connecter lorsque la variable d’environnementSSH_AUTH_SOCK
est vide (bz#2936) ; -
ssh
conservait un socket redondant dessh-agent
(un reste de l’authentification) pendant toute la connexion, ce n’est maintenant plus le cas (bz#2912).
Portabilité
Il existe deux versions d’OpenSSH : une dédiée à OpenBSD et une deuxième contenant des correctifs de compatibilité pour les autres systèmes d’exploitation, appelée version portable.
Pour cette version 8.0, les améliorations concernent avant tout l’utilisation dans Cygwin :
-
sshd
est lancé en tant qu’utilisateur SYSTEM autant que possible, en utilisant S4U pour la création de jeton si cela prend en charge le logon MsV1_0 S4U ; - toujours pour
sshd
, du code spécifique a été ajouté pour respecter l’insensibilité à la casse des utilisateurs et groupes ; -
sshd
n’initialise pas la variable d’environnement$MAIL
si la configuration spécifieUsePAM=yes
, car PAM s’en charge (bz#2937) ; - le service
sshd
se nomme dorénavantcygsshd
pour éviter une collision avec le portage d’OpenSSH réalisé par Microsoft ; - la compilation avec la branche
-dev
d’OpenSSL (3.x) est dorénavant autorisée ; - divers problèmes de compilation suivant les versions d’OpenSSL et les options de configuration et ont été corrigés (bz#2931 et bz#2921) ;
- amélioration des messages d’avertissement dans la mise en place du service Cygwin et retrait du codage en dur du nom du service (bz#2922).
Aller plus loin
- OpenSSH (144 clics)
- Notes de version de la 8.0 (texte) (103 clics)
- Notes de version (historique jusqu’à la version 1.2.2p1) (80 clics)
- OpenBSD (87 clics)
- Annonce d'OpenSSH 8.0 sur la liste de diffusion openssh-unix-announce (88 clics)
- LinuxFr.org : OpenSSH 7.9 (111 clics)
# Excellente dépêche
Posté par Dafyd . Évalué à 5.
Merci pour cette excellente dépêche !
# Bien visé ! Non ???
Posté par Arthur Accroc . Évalué à 3.
On peut peut-être considérer qu’il a réussi, non ?
Surtout que de nos jours, on ne peut plus trop se permettre d’utiliser telnet et rlogin pour de l’administration distante…
J’aurais juste mis « propose ».
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Bien visé ! Non ???
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 2.
Oui, c'est d'ailleurs écrit dans la phrase d'après ;)
# Communiqués
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
C'est fun le "é" de "Keeping your communiqués secret" en anglais…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.